Understanding CORS Safelisted Request and Response Headers

Today we’re zoning in on a more nuanced aspect of CORS: safelisted request and response headers.

This post aims to demystify these headers, elucidating their importance, functionality, and how to effectively work with them to ensure seamless, cross-origin requests in your applications.

First things first, by only using safelisted headers, you can avoid triggering preflight requests. This can make working with CORS a lot simpler and also provides a small performance boost to your application.

We’ll now delve into the specifics and differences of safelisted request and response headers.

What Are CORS Safelisted Request Headers?

When a web application makes a cross-origin HTTP request, the browser imposes restrictions to safeguard against malicious activities, such as sending along various request headers.

However, certain “safelisted” request headers are deemed secure enough to be included in cross-origin requests without triggering a preflight request to ask for permission from the server.

The Safelisted Request Headers

These headers are universally recognized as safe:

• Accept
• Accept-Language
• Content-Language
• Content-Type (with restrictions)
• DPR
• Downlink
• Save-Data
• Viewport-Width
• Width

Among these, Content-Type deserves special mention. It’s only considered safelisted if its value is one of the following:

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

Why They’re Safelisted

The rationale behind safelisting these headers is their limited capacity to trigger or relay sensitive operations from the server.

Essentially, they provide necessary information about the request or the client’s preferences without exposing or manipulating server-side data or metadata in a manner that could be exploited.

Understanding CORS Safelisted Response Headers

On the flip side, CORS safelisted response headers are those the browser allows a script to access from the response to a cross-origin request, without the server having to explicitly expose them via the Access-Control-Expose-Headers header.

The Safelisted Response Headers

The safe response headers include the following:

• Cache-Control
• Content-Language
• Content-Type
• Expires
• Last-Modified
• Pragma

These headers are primarily related to caching and metadata about the response content. They’re considered non-sensitive and generally necessary for the web applications to function correctly or efficiently.

The Significance of These Headers

The inclusion of these headers in responses to cross-origin requests ensures that essential functionality related to caching, content negotiation, and basic metadata retrieval works out of the box.

It streamlines the development process, allowing developers to focus on more critical aspects of their application’s cross-origin communication setup.

Working with Safelisted Headers

To effectively utilize these safelisted headers in your applications, follow these best practices:

• Limit Custom Headers: Only use custom headers when absolutely necessary. Rely on safelisted headers as much as possible to avoid triggering preflight requests.
• Properly Configure Content-Type: When sending data, ensure the Content-Type header is set to one of the safelisted values. This can prevent unexpected preflight requests.
• Understand Browser Differences: Be aware that browsers might implement the CORS specification slightly differently. Testing across browsers is crucial to identify any peculiarities.
• Server-Side Configuration: For response headers not safelisted, remember to configure your server to include them in the Access-Control-Expose-Headers header if they need to be accessible to the client-side application.

If you are unsure how to properly configure your server to allow your client-side application to access certain response headers, refer to our CORS config generator.

Conclusion

CORS safelisted request and response headers play a pivotal role in the seamless operation of cross-origin requests in web applications. By using no other headers than the safelisted ones, you can avoid triggering preflight requests, which can significantly improve the performance and simplicity of your application.

If you'd like to hear about new tools and features we release, sign up for our newsletter. Zero spam.